1. Field of the Invention
The present invention relates to migrating point to point protocol (PPP) functions for customer access of a wide area network to the Internet Protocol (IP).
2. Description of the Related Art
Networks of general purpose computer systems and special devices connected by external communication links are well known. The networks often include one or more network devices that facilitate the passage of information between the computer systems. A network node is a network device or computer system or special device connected by the communication links.
Information is exchanged between network nodes according to one or more of many well known, new or still developing protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other based on information sent over the communication links. The protocols are effective at different layers of operation within each node, from generating and receiving physical signals of various types, to selecting a link for transferring those signals, to the format of information indicated by those signals, to identifying which software application executing on a computer system sends or receives the information. The conceptually different layers of protocols for exchanging information over a network are described in the Open Systems Interconnection (OSI) Reference Model. The OSI Reference Model is generally described in more detail in Section 1.1 of the reference book entitled Interconnections Second Edition, by Radia Perlman, published September 1999, which is hereby incorporated by reference as though fully set forth herein.
Communications between nodes are typically effected by exchanging discrete packets of data. Each packet typically comprises 1] header information associated with a particular protocol, and 2] payload information that follows the header information and contains information that may be processed independently of that particular protocol. In some protocols, the packet includes 3] trailer information following the payload and indicating the end of the payload information. The header includes information such as the source of the packet, its destination, the length of the payload, and other properties used by the protocol. Often, the data in the payload for the particular protocol includes a header and payload for a different protocol associated with a different, higher layer of the OSI Reference Model. The header for a particular protocol typically indicates a type for the next protocol contained in its payload. The next protocol is said to be encapsulated in the particular protocol. The headers included in a packet traversing multiple heterogeneous networks, such as the Internet, typically include a physical (layer 1) header, a data-link (layer 2) header, an internetwork (layer 3) header and a transport (layer 4) header, as defined by the Open Systems Interconnection (OSI) Reference Model.
Some protocols span the layers of the OSI Reference Model. For example, the Ethernet local area network (LAN) protocol includes both layer 1 and layer 2 information. The International Electrical and Electronics Engineers (IEEE) 802.3 protocol, an implementation of the Ethernet protocol, includes layer 1 information and some layer 2 information.
One such layer 2 protocol is the Point to Point Protocol (PPP) between a host computer on a local area network and a network node that provides access to a wide area network, such as the Internet. Some protocols, including PPP, pass protocol-related information among two or more network nodes in special control packets that are communicated separately and which include a payload of information used by the protocol itself rather than a payload of data to be communicated for another application. These control packets and the processes at network nodes that utilize the control packets are said to be in another dimension, a “control plane,” distinct from the “data plane” dimension that includes the data packets with payloads for other applications. For example, authentication information used to authenticate users and layer 3 address assignment information used by routers to direct data packets according to their layer 3 addresses are passed between nodes in PPP control messages in the PPP control plane.
PPP provides a standard method for transporting any of multiple protocol data packets (also called frames, datagrams and cells, and used interchangeably herein) over point-to-point links. PPP is defined in an Internet Engineering Task Force (IETF) request for comments document (RFC) numbered 1661, dated July 1994, the entire contents of which are hereby incorporated by reference as if fully set forth herein. Copies of RFC 1661 and other RFCs cited below are available at the World Wide Web domain ietf.org. PPP has been used extensively to connect users at a home site to a remote network using modems and telephone copper loop infrastructure. PPP provides a robust control plane for signaling line characteristics, network protocol parameters, and user-level authentication. In large service provider networks, the user authentication models are generally well entrenched, including, but not limited to, custom-built applications for communicating policy to network equipment and to track billing information.
For applications in which multiple hosts on a shared Ethernet establish PPP sessions to multiple destinations via one or more bridging modems, a PPP over Ethernet (PPPoE) specification has been developed. PPPoE is intended to be used with broadband remote access technologies that provide a bridged Ethernet topology, when access providers wish to distinguish different users connected via the same modem to the remote network. PPP provides this distinction by opening different sessions with different users. PPPoE is described in IETF RFC 2516, the entire contents of which are hereby incorporated by reference as if fully set forth herein. After establishing a PPP session, IP data packets are sent encapsulated in PPPoE.
There is a trend among network service providers to move to Ethernet and IP as the only layer two and layer three protocols between end nodes at a user site and end nodes on the remote network to which access is sought. One reason given for this trend is a desire to make use of IP-based quality of service (QoS) capabilities available in access network equipment. Another reason given is to reduce complexity because data packets can be transmitted from one portion of the network infrastructure to another without translating between layer 2 protocols. Another reason given is that using IP over Ethernet will improve the bandwidth utilization per transmitted frame due to a lower protocol overhead.
One approach is to eliminate PPP and PPPoE; and provide the PPP functions using IP-based functions. For example, it has been proposed to use International Electrical and Electronics Engineers standard 802.1x or web portal methods for authentication, and to use the Dynamic Host Configuration Protocol (DHCP) for assigning IP addresses. A justification offered for this approach is that, when all encapsulated data packets are IP, the multi-protocol encapsulation capability of PPP is not valuable.
There are some disadvantages to eliminating PPP. For example, web portal based authentication has drawbacks in that it requires a specific application (web browser) to be activated before anything can happen. The existing IP-based functions do not perform all the functions performed by PPP. Some of these protocols would have to be extended to perform the missing functions. For example, DHCP would have to be extended to perform user authentication and integration with an authorization server, configure link-level parameters such as maximum reception unit (MRU), and include a connection “keep-alive” mechanism, among other tasks, in order to encompass all of the functionality that PPP offers today.
In one approach, described in RFC 3118 on DHCP authentication, a mechanism is presented that is directed to authenticating the DHCP messages themselves to ensure that they did not get altered in transmit, rather than authenticating the user.
PPP provides a “keep-alive” mechanism for detecting when a session is active and available so that reallocation of an IP address or billing can take place on session termination. DHCP does not have any mechanism today apart from a lease timeout. In one approach, DHCP is used with very short lease times, e.g., as short as 5 seconds. A problem with this approach is that devices for users who engage in sessions that last longer than the lease time have to negotiate new leases with the DHCP server, increasing the consumption of network resources both in terms of traffic volume and computational time at a node that hosts a DHCP server.
Also, as pointed out above, especially in large service provider networks, PPP-based functions are generally well entrenched with provider-specific extensions. For example, some provider-specific extensions provide authorization to determine whether an authentic user is in good standing for receiving one or more services, e.g., for paid-up basic services, for voice services, or for a particular quality of service, or some combination. Many of these extensions involve a Broadband Remote Access Server (BRAS) hooking into an Authentication, Authorization, Accounting (AAA) server like the Remote Authentication Dial-In User Service (RADIUS) server. Neither RFC 3118 nor DHCP address determining whether an authentic user is actually authorized to access any particular services on the network or involve hooking into an AAA server. A wholesale replacement of general PPP functions with IP will not address any provider-specific extensions. Some transition period is needed to give the provider time to adapt the provider-specific extensions to the IP mechanisms.
Based on the foregoing, there is a clear need for techniques that migrate one or more PPP functions to IP over Ethernet infrastructure but that do not suffer all the disadvantages of the prior art approaches. In particular there is a need within DHCP to emulate PPP interactions with an AAA server. Furthermore, there is a need to entirely replace PPP functionality between customer premises nodes and a provider remote access server using DHCP.
The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not to be considered prior art to the claims in this application merely due to the presence of these approaches in this background section.